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• Propulsion Systems is leading an effort to improve our requirements and verification 
and analysis data management processes by integrating them into TcUA (Teamcenter, 
Teamcenter Unified Architecture) 

• Expected benefits: 

> Facilitates getting the right data to the right person at the right time to make the right 
decision 

> Facilitates proper documentation of analysis inputs 

> Enables integrated change management 
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Orbital ATK Strategic PLM Vision 
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• End-to-end program management in TcUA 

• Reuse data in later project phases, enter data once and reuse multiple times 

• Interrelate data elements to allow integrated change management 
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Requirements and Analysis Interactions 
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• Focus for this presentation is on managing interactions between requirements and 
verification data management and analysis data management 

• Types of requirement/analysis interaction 

> Concept development 

> Requirement derivation 

> Design verification 

> Analysis scope definition 

> Change management 

> MRB evaluation. 

• These interactions are not independent of each other. Data from one interaction 
should be leveraged and sometimes reused for other interactions. 


Current Condition 
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• Interactions between requirements and analysis are not as well coupled as desired 

> Requirement inputs into analysis are often verbal with little or no documentation 

- This includes design development requirements and verification requirements 

> Changes to requirements are often not communicated to analysts 

> Analysts are typically not closely involved in the requirement definition process 

> Analysis feedback to requirements is likewise often verbal with little or no 
documentation 

• Data management 

> Data management for requirements and verification utilizes TcSE 

> Analysis data management has a wide range of implementations 

- Typically files/data are stored on hard drives or shared network drives 

- Formal ePIC documentation typically limited to customer deliverables 

> Connections between analysis and requirements are typically either managed 
manually in TcSE or only through human memory 


Current Condition - Challenges 
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• Some of the challenges associated with the current condition are as follows: 

> Greater risk of miscommunication 

- Verbal communication relies on human memory 

- Greater risk of misinterpretation without ability to refer to written communication for 
clarification 

- Can result in inconsistency between desired and actual analysis results. Even if this 
inconsistency is discovered it would still drive rework. 

> Greater risk of data loss 

- Inconsistent data management techniques can inhibit data retrieval 

- Data may be inadvertently lost during hardware migration or personnel turn-over 

- Can result in unnecessary rework 

> Greater risk of data inaccessibility 

- Difficult to perform complete impact evaluation, often rely on human memory 

- Analysts do not have direct access to requirements data 

- Systems engineers to not have direct access to analysis data 


Target Condition 
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• Manage requirement and analysis data in the same system (TcUA) 

• Interconnect related data through database relations (example: trace links) 

• Document analysis inputs through soft release/hard release processes 

• Engineering processes that drive communication and interaction between systems 
engineering and analysts 

• Benefits: 

> Decreased risk of miscommunication 

- Documented inputs into analysis process 

- Document outputs from analysis process 

> Decreased risk of data loss. 

- TcUA database is backed up and protected during hardware migration 

- User data in TcUA is not loss during personnel turn-over 

> Decreased risk of data inaccessibility 

- Accessibility via database relations between data elements 


Stakeholder Needs 
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• Stakeholder needs gathered to allow TcUA architecture development and evaluation 

• For this paper the focus was on the needs relating to requirement/analysis integration 

• User needs (generalized): 

> Systems engineer (req & verif) needs: 

- Accessibility* of analysis data: 

° Analysis inputs 
° Assumptions/simplifications 
° Type of analysis performed 
° Applicable tools 
° Detailed results 
° Summarized results 

- Apply problem report to requirement and analysis data elements 

• Accessibility is about providing the right data to the right person at the right time to 
make the right decision 


Stakeholder Needs (cont.) 
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• User needs (generalized, cont.): 

> Analysis engineer needs: 

- Accessibility of the engineering analysis request (EAR) 

- Accessibility of the requirements model 

- Input stability (soft release/hard release) 

- Change visibility 

> Design engineer needs: 

- Accessibility of applicable requirements 

- Accessibility of verification objectives 

- Accessibility of analyses 


Solution Architecture - Design Development 
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Database Relations 
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• Investing time in creating/maintaining relations pays off in the long run 

> Data is readily accessible to support engineering processes 

> Enables effective change management 


Engineering Analysis Request 


• Investing time in planning analysis 
before execution is consistent with 
PES continuous improvement process 

• Analysis results will be applicable for 
the intended use the first time* 

• Deliberate decision about input 
maturity minimizes unnecessary 
analysis iterations 


* “There is never enough time to do it 
right the first time, but there is always 
enough time to do it over.” - anonymous 
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Solution Validation Testing 
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• iDev testing (individual development environment on virtual machine) 

> Primarily tested by engineers developing the requirements and analysis data 
management architectures 

> Work out details of requirement/analysis interactions 

> Validate the concept prior to deployment to development server 

• Development server testing 

> Involvement of key supporters from several different sites 

> Involvement of systems engineers and analysts 

> Validate that solution works with multiple users 

> Validate accessibility of data to users 

> Get early feedback from users on the progress of the solution architecture 


Case Study 1: Simple Timing Tolerance Analysis 
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• Input: 

> Dummy customer requirement for FTS S&A safe timing 

• Objectives: 

> Demonstrate an analysis performed by systems engineer using spreadsheet 

> Demonstrate derivation of requirements through analysis 

> Demonstrate iteration of the derivation process driven by req and design changes 

> Demonstrate reuse of req derivation analysis for design verification 

> Demonstrate data accessibility 


Case Study 2: Hardware Structural Analysis 


Orbital ATK 


• Inputs: 

> Dummy customer requirements for loads and factors of safety 

> Dummy preliminary design concept 

• Objectives: 

> Demonstrate a more complex analysis performed by a dedicated analyst 

> Demonstrate design analysis driven through verification objectives 

> Demonstrate generation of compliance statements 

> Demonstrate data accessibility 


Case Study 3: Thermal Conditions 
Determination Analysis 
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• Inputs: 

> Dummy customer requirements for loads and factors of safety 

> Dummy preliminary design concept 

• Objectives: 

> Demonstrate a more complex analysis performed by a dedicated analyst 

> Demonstrate derivation of requirements through analysis 

> Demonstrate iteration of the derivation process driven by req and design changes 

> Demonstrate the evolution of analysis when design matures to a higher fidelity 
analysis 

- Create traceability between new and old analyses 

> Demonstrate generation of compliance statements 

> Demonstrate data accessibility 


Conclusion 
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• The proposed solution architecture for requirements and analysis data management in 
TcUA is expected to provide the following benefits 

> Facilitates getting the right data to the right person at the right time to make the right 
decision 

> Facilitates proper documentation of analysis inputs 

> Enables integrated change management 

• Continuing efforts to validate these solutions and expand our TcUA capability should 
be supported by management through budget and resource allocation 


